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Abstract 


This document lists IANA Considerations for Remote Procedure Call 
(RPC) Network Identifiers (netids) and RPC Universal Network 
Addresses (uaddrs). This document updates, but does not replace, RFC 
1833. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc5665. 


Copyright Notice 


Copyright (c) 2010 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Introduction and Motivation 


The concepts of an RPC (defined in RFC 5531 [4]) Network Identifier 
(netid) and an RPC Universal Address (uaddr) were introduced in RFC 
1833 [1] for distinguishing network addresses of multiple protocols 
and representing those addresses in a canonical form. RFC 1833 
states that a netid "is defined by a system administrator based on 
local conventions, and cannot be depended on to have the same value 
on every system". (The netid is contained in the field r_netid of 
the data type rpcb_entry, and the uaddr is contained in the field 
r_addr of the same data type, where rpcb_entry is defined in RFC 
1833.) Since the publication of RFC 1833, it has been found that 
protocols like Network File System version 4 (NFSv4.0) [5] and RPC/ 
RDMA (Remote Direct Memory Access) [6] depend on consistent values of 
netids and representations of uaddrs. Current practices tend to 
ensure this consistency. Thus, this document identifies the 
considerations for IANA to establish registries of netids and uaddr 
formats for RPC and specifies the initial content of the two 
registries. 


Requirements Language 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [2]. 


Considerations for the Netid of the Stream Control Transmission 
Protocol 


The Stream Control Transmission Protocol (SCTP) (described in RFC 
4960 [7]) is a connection-oriented protocol that supports both byte- 
streamed and record-oriented data transfer. When the "sctp" and 
"sctp6" netids are used, the Open Network Computing (ONC) RPC Record 
Marking standard (see Section 11 of RFC 5531 [4]) is not used; 
instead, SCTP’s native record-oriented data transfer is used. 


Security Considerations 

Since this document is only concerned with the IANA management of the 
Network Identifier (netid) and Universal Network Addresses (uaddrs) 
format registry, it raises no new security issues. 


IANA Considerations 


This section uses terms that are defined in RFC 5226 [8]. 
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5.1. IANA Considerations for Netids 


IANA has created a registry called "ONC RPC Netids". The remainder 
of this section describes the registry. 


All assignments to the ONC RPC Netids registry are made on one of two 
bases: 


o A First Come First Served basis subregistry per Section 4.1 of RFC 
5226. 


o A Standards Action basis subregistry per Section 4.1 of RFC 5226. 


The eXternal Data Representation (XDR) encoding allows netids to be 
up to 2%32 - 1 octets in length, but the registry will only allow a 
much shorter length. Assignments made on a Standards Action basis 
should be assigned netids 1 to 8 octets long. Assignments made on a 
First Come First Served basis should be assigned netids 9 to 128 
octets long. Some exceptions are listed in Table 2. 


Some portion of the netid name space is Reserved: 
o All netids, regardless of length, that start with the prefixes 


"STDS" or "FCFS" are Reserved, in order to extend the name space 
of either Standards Action or First Come First Served bases. 


o To give the IESG the flexibility in the future to permit Private 
and Experimental Uses, all netids with the prefixes "PRIV" or 
"EXPE" are Reserved. 


o To prevent confusion with the control protocol by the same name 
[9], netids with the prefix "ICMP" are Reserved. 


o Since netids are not constructed in an explicit hierarchical 
manner, this document does not provide for Hierarchical Allocation 
of netids. Nonetheless, all netids containing the octet "." are 
Reserved for future possible provision of Hierarchical Allocation. 


o The zero length netid is Reserved. 


A recommended convention for netids corresponding to transports that 
work over the IPv6 protocol is to have "6" as the last character in 
the netid’s name. 


There are two subregistries of netids: one for Standards Action 
assignments and one for First Come First Served assignments. Each 
registry of netids is a list of assignments, each containing five 
fields for each assignment. 
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A US-ASCII string name that is the actual netid. The netid 
should be 1 to 8 octets long for the Standards Action 
subregistry, and 9 to 128 octets long for the First Come First 
Served subregistry. The netid MUST NOT conflict with any other 
registered netid. Despite the fact that netids are case 
sensitive, the netid, when mapped to all upper case, MUST NOT 
conflict with the value of any other registered netid after the 
registered netid is mapped to upper case. In addition, when 
mapped to upper case, the prefix of the netid MUST NOT be equal 
to a Reserved prefix. 


A constant name that can be used for software programs that wish 
to use the transport protocol associated with the netid. The 
name of the constant typically has the prefix "NC_", and a suffix 
equal to the upper-case version of the netid. This constant name 
should be a constant that is valid in the ’C’ programming 
language. This constant name MUST NOT conflict with any other 
netid constant name. Constant names with the prefix "NC_STDS", 
"NC_FCFS", "NC_PRIV", "NC_EXPE", and "NC_ICMP" are Reserved. 
Constant names with a prefix of "NC_" and a total length of 11 
characters or less should be for assignments made on the 
Standards Action basis. The constant "NC_" is Reserved. The 
constant name can be 1 to 131 octets long. 


Given the typical derivation of the constant name from the netid, 
the registration of the constant might be considered redundant. 
This is not always true. For example, a netid might use a 
character that is not valid in the programming language. The 
first entry of Table 1 provides such an example. 


A description and/or a reference to a description of how the 
netid will be used. For assignments made on a First Come First 
Served basis, the description should include, if applicable, a 
reference to the transport and network protocols corresponding to 
the netid. For assignments made on a Standards Action basis, the 
description field must include the RFC numbers of the protocol 
associated with the netid, including, if applicable, RFC numbers 
of the transport and network protocols. 


A point of contact of the registrant. For assignments made on a 
First Come First Served basis: 


* the point of contact should include an email address. 
* subject to authorization by a Designated Expert, the point of 
contact may be omitted for extraordinary situations, such as 


the registration of a commonly used netid where the owner is 
unknown. 
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idad: 


The 


For assignments made on a Standards Action basis, the point of 
contact is always determined by IESG. 


A numerical value, used to cross reference the netid assignment 
with an assignment in the uaddr format registry (see 

Section 5.2). If the registrant is registering a netid that 
cross references an existing assignment in the uaddr format 
registry, then the registrant provides the actual value of the 
cross reference along with the date the registrant retrieved the 
cross reference value from the uaddr format registry. If the 
registrant is registering both a new netid and new uaddr format, 
then the registrant provides a value of TBD1 in the netid 
request, and uses TBD1 in the uaddr format request. IANA will 
then substitute TBD1 for the cross reference number IANA 
allocates. Note that if a document requests multiple netid and 
uaddr assignments, each additional uaddr format cross reference 
will be identified as TBD2, TBD3, ..., etc. 


Initial Registry 


initial list of netids is broken into two subregistries: those 


assigned on a First Come First Served basis in Table 1 and those 
assigned on a Standards Action basis in Table 2. These lists will 
change as IANA registers additional netids as needed, and the 
authoritative list of registered netids will always live with IANA. 
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RFC 5665 
4+------------- 4+-------------- 
| Netid | Constant 
| | Name 
+------------- +-------------- 
| "o" | NC_NOPROTO 
| | 
| | 
| "ticlts® | NC_TICLTS 
| | 
| | 
| | 
| | 
| | 
| | 
| "ticots" | NC_TICOTS 
| | 
| | 
| | 
| | 
| | 
| | 
| "ticotsord" | NC_TICOTSORD 
| | 
| | 
| | 
+------------- 4+----------- 


PoC: 


RPC Netids 


+ 

| Description and/or 

| Reference 

+ a A A A a rt es ee ee gt 

| RFC1833 [1], 

| Section 5.2.3.2 of RFC 

| 5665 

| The loop back 

| connectionless transport 

used in System V Release 

| 4 and other operating 

| systems. Although this 

| assignment is made on a 

| First Come First Served 

| basis and is fewer than 

| nine characters long, the 

exception is authorized. 

| See [10]. 

| The loop back 

| connection-oriented 

| transport used in System 

| V Release 4 and other 
operating systems. See 

| [10]. Although this 

| assignment is made on a 

| First Come First Served 

| basis and is fewer than 

| nine characters long, the 
exception is authorized. 

| The loop back 

| connection-oriented with 

| orderly-release transport 

| used in System V Release 
4 and other operating 
systems. See [10]. 


----- ++ 
PoC | CR | 
| | 
----- ++ 
liado. Hi 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
[o ] 
| | 
| | 
| | 
| | 
| | 
| | 
po | 
| | 
| | 
| | 
----- ++ 


Table 1: Initial First Come First Served Netid Assignments 


Point of Contact. 


CR: Cross Reference to the Uaddr Format Registry. 
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"sctp6" 


"tcp6" 


" udp " 


| 
| 
| 
| "top" 
| 
| 
| 
| "udp6" 


Dice 2u 


Per Section 5.2 of RFC 5226, 


Name 


NC_SCTP6 


Table 2: 


+ —— + 


| 
| 
| 
| 
| 
+ 


RPC Netids 

RFC(s) and Description 
needed) 

RFC 5666 [6], RFC 791 
RFC 5666 [6], RFC 2460 
RFC 4960 [7], RFC 791 
Section 3 of RFC 5665 
RFC 4960 [7], RFC 2460 
Section 3 of RFC 5665 
RFC 793 [13], RFC 791 
Section 11 of RFC 5531 
RFC 793 [13], RFC 2460 
Section 11 of RFC 5531 
RFC 768 [14], RFC 791 
RFC 768 [14], RFC 2460 


Updating Registrations 


[11] 
[12] 
[11], 


[12], 


[11], 
[4] 
[12], 
[4] 

[11] 
[12] 


+ 
| 
| 

+ 
| 
| 
| 
| 
| 
| 
| 
| 

+ 


------ ++ 
PoC | CR | 
| | 
------ ++ 
IESG | 2 | 
IESG | 3 | 
IESG | 2 | 
| | 

IESG | 3 | 
IESG | 2 | 
| | 

IESG | 3 | 
| | 

IESG | 2 | 
IESG | 3 | 
------ +----+ 


Initial Standards Action Netid Assignments 


the registrant is always permitted to 


update a registration made on a First Come First Served basis 


"subject to the same constraints and review as with new 


registrations". The IESG or a Designated Expert is permitted to 


update any registration made on a First Come First Served basis, 
which normally is done when the PoC cannot be reached in order to 


make necessary updates. 
but are not limited to: 


include, 


Examples where an update would be needed 
the email address or other contact 


information becomes invalid; the reference to the corresponding 


protocol becomes obsolete or unavailable; 
replaced in such a way that the scope of netids changes, 


additional fields in the assignment. 


Only the 


IESG, 


on the advice of a Designated Expert, 


registration made on a Standards Action basis. 


Dio Los 


IANA Considerations for Uaddr Formats 


RFC 1833 is updated or 


requiring 


can update a 


IANA has created a registry called "ONC RPC Uaddr Format Registry" 


(called the "format registry" 
The remainder of this section describes the registry. 
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All assignments to the format registry are made on one of two bases: 


o 


o 


First Come First Served basis per Section 4.1 of RFC 5226. 


Standards Action per Section 4.1 of RFC 5226. 


The registry of formats is a list of assignments, each containing 
four fields for each assignment. 


ale 


The basis for the assignment, which can be either FCFS for First 
Come First Served assignments or STDS for Standards Action 
assignments. 


A description and/or reference to a description of the actual 
uaddr format. Assignments made on a Standards Action basis 
always have a reference to an RFC. 


For assignments made on a First Come First Served basis, a point 
of contact, including an email address. Subject to authorization 
by a Designated Expert, the point of contact may be omitted for 
extraordinary situations, such as the registration of a commonly 
used format where the owner is unknown. For assignments made on 
a Standards Action basis, the point of contact is always 
determined by the IESG. 


A numerical value, used to cross reference the format assignment 
with an assignment in the netid registry. The registrant 
provides a value of TBD1 for the cross reference field when 
requesting an assignment. IANA will assign TBD1 to a real value. 
Note that if a document requests multiple uaddr assignments, each 
additional uaddr format cross reference will be identified as 
TBD2, TBD3, ..., etc. 


All requests for assignments to the format registry on a Standards 
Action basis are only for Standards Track RFCs approved by the IESG. 


AO 


Initial Registry 


The initial list of formats is in Table 3. This list will change as 
IANA registers additional formats as needed, and the authoritative 
list of registered formats will always live with IANA. 
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+= HE o SO AR += ++ 
| Basis | Description and/or Reference | Poc | cr | 
Ho A O O += ++ 
| FCFS | System V Release 4 loopback transport uaddr | Br e 
| | format. Section 5.2.3.1 of RFC 5665 | | 
| FCFS | Uaddr format for NC_NOPROTO. Section 5.2.3.2 | Hei l 
| | of RFC 5665 | | | 
| STDS | Uaddr format for IPv4 transports. | IESG | 2 | 
Section 5.2.3.3 of RFC 5665 | | 
| STDS | Uaddr format for IPv6 transports. | IESG 3 
| | Section 5.2.3.4 of RFC 5665 | | 
tastes 2 pas A E atete ++ 


Table 3: Initial Format Assignments 
5.2.2. Updating Registrations 


The registrant is always permitted to update a registration made on a 
First Come First Served basis "subject to the same constraints and 
review as with new registrations." The IESG is permitted to update 
any registration made on a First Come First Served basis, which 
normally is done when the PoC cannot be reached in order to make 
necessary updates. Examples where an update would be needed include, 
but are not limited to: the email address or other contact 
information becomes invalid; the reference to the format description 
becomes obsolete or unavailable; RFC 1833 is updated or replaced in 
such a way that the scope of uaddr formats changes, requiring 
additional fields in the assignment. 


Only the IESG, on the advice of a Designated Expert, can update a 
registration made on a Standards Action basis. 


5.2.3. Uaddr Formats 

5.2.3.1. Uaddr Format for System V Release 4 Loopback Transports 
Although RFC 1833 specifies the uaddr as the XDR data type string 
(hence, limited to US-ASCII), implementations of the System V Release 
4 loopback transports will use an opaque string of octets. Thus, the 
format of a loopback transport address is any non-zero length array 
of octets. 


5.2.3.2. Uaddr Format for Netid "-" 


There is no address format for netid "-". This netid is apparently 
for internal use for supporting some implementations of RFC 1833. 
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5.2.3.3. Uaddr Format for Most IPv4 Transports 


Most transport protocols that operate over IPv4 use 16-bit port 
numbers, including RDMA [6], SCTP [7], TCP [13], and UDP [14]. The 
format of the uaddr for the above 16-bit port transports (when used 
over IPv4) is the US-ASCII string: 


h1.h2.h3.h4.p1.p2 


The prefix "h1.h2.h3.h4" is the standard textual form for 
representing an IPv4 address, which is always four octets long. 
Assuming big-endian ordering, hl, h2, h3, and h4 are, respectively, 
the first through fourth octets each converted to ASCII-decimal. The 
suffix "pl.p2" is a textual form for representing a service port. 
Assuming big-endian ordering, pl and p2 are, respectively, the first 
and second octets each converted to ASCII-decimal. For example, if a 
host, in big-endian order, has an address in hexadecimal of 
0xC0000207 and there is a service listening on, in big-endian order, 
port 0xCB51 (decimal 52049), then the complete uaddr is 

"EOZ ezo LOL. 


5.2.3.4. Uaddr Format for Most IPv6 Transports 


Most transport protocols that operate over IPv6 use 16-bit port 
numbers, including RDMA [6], SCTP [7], TCP [13], and UDP [14]. The 
format of the uaddr for the above 16-bit port transports (when used 
over IPv6) is the US-ASCII string: 


x1:x2:x3:x4:x5:x6:x7:x8.p1.p2 


The suffix "pl.p2" is the service port, and is computed the same way 
as with uaddrs for transports over IPv4 (see Section 5.2.3.3). The 
prefix "x1:x2:x3:x4:x5:x6:x7:x8" is the preferred textual form for 
representing an IPv6 address as defined in Section 2.2 of RFC 4291 
[3]. Additionally, the two alternative forms specified in Section 
2.2 of RFC 4291 are also acceptable. 


5.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6 


As ICMP is not a true transport, there is no uaddr format for ICMP. 
The netid assignments "icmp" and "icmp6" and their shared uaddr 
"format" are listed to prevent any registrant from allocating the 
netids "icmp" and "icmp6" for a purpose that would likely cause 
confusion. 
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5.3. Cross Referencing between the Netid and Format Registry 
The last field of the netids registry is used to cross reference with 
the last field of the format registry. IANA is under no obligation 
to maintain the same numeric values in cross references when updating 
each registry; i.e., IANA is free to "re-number" these corresponding 
fields. However, if IANA does so, both the netid and format 
registries must be updated atomically. 

5.4. Port Assignment for NFS over SCTP 
Port 2049 is assigned to NFS over SCTP for the sctp and sctp6 netids. 
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